Digital media playback capabilities may be incorporated into a wide range of devices, including digital televisions, including so-called “smart” televisions, set-top boxes, laptop or desktop computers, tablet computers, digital recording devices, digital media players, video gaming devices, cellular phones, including so-called “smart” phones, dedicated video streaming devices, and the like. Digital media content (e.g., video and audio) may originate from a plurality of sources including, for example, over-the-air television providers, satellite television providers, cable television providers, online media services, including, so-called streaming services, and the like. Digital media content may be transmitted from a source (e.g., an over-the-air television provider) to a receiver device (e.g., a digital television) according to a transmission standard. Examples of transmission standards include Digital Video Broadcasting (DVB) standards, Hybrid Broadcast and Broadband Television (HbbTV) 2.0 standard, and standards developed by the Advanced Television Systems Committee (ATSC), including, for example, the ATSC 2.0 standard. The ATSC is currently developing the so-called ATSC 3.0 standard.
In addition to defining how digital media content may be transmitted from a source to a receiver device, transmission standards may define how data may be transmitted to support so-called second screen applications. Second screen applications may refer to applications operating on a device other than a primary receiver device. For example, it may be desirable for a tablet computer to run an application in conjunction with the media playback on the primary media rendering device, where the application enables an enhanced viewing experience. Current techniques for enabling second screen applications may be less than ideal.
A video service is capable of sending audiovisual content to a receiving device. The receiving audiovisual device typically presents the content to the viewer, such as on a television device. In some cases, the viewer would like to use their mobile device, such as a mobile phone, to interact with the video content. However, how to most effectively interact with the audiovisual content on the receiving device using the mobile phone tends to be problematic due to synchronization issues. In one case the viewer may want to receive audiovisual content on a receiver such as a television device. At the same time the user may want to receive adjunct associated content on a second screen, e.g. a mobile device such as a smartphone or a tablet. The content received on the second screen device may be same as or alternate content associated with the audiovisual content being received on the television. The user may typically like these two contents be presented on the primary and second screen device in a synchronized manner.
As described above, transmission standards may define how data may be provided to a companion device to support second screen applications. ATSC Candidate Standard: Interactive Services Standard (A/105:2014), S13-2-389r7, 12 Dec. 2013, Rev. 7, 24 Apr. 2014 (hereinafter “ATSC 2.0 A105”), specifies services that can be provided by a device configured to receive an ATSC 2.0 transport stream to support the display of content related to an A/V broadcast by applications running on second screen devices. According to ATSC 2.0 A105, an ATSC 2.0 receiver may support the following services for the use by a second screen application: trigger delivery service, two-way communications service, and optionally HTTP proxy server service. In ATSC 2.0 A105, trigger delivery service is limited to an ATSC 2.0 receiver simply passing triggers including limited information to a second screen device. The amount of information that may be included in a trigger is limited. Further, in ATSC 2.0 A105, two-way communications service simply provides a TCP/IP connection for a primary device and a second screen device to communicate. That is, each of the primary device and the second screen device must be configured to transmit and receive data according to a proprietary format. This typically results in devices that have different manufacturers being incompatible. In ATSC 2.0 A105, HTTP proxy server service simply provides a mechanism for a primary device to act as a proxy for a second screen device, e.g., when a second screen device has limited Internet connectivity. Thus, each of the services for supporting second screen applications in ATSC 2.0 A105 are limited and do not provide content information to an application running on a companion device in an efficient manner. ATSC 2.0 A105 does not define actual message content, message formats and various types of message exchanged between a primary device and a companion device. In contrast this disclosure describes this type of information.
As described above, transmission standards may define how data may be provided to a companion device to support second screen applications. Hybrid Broadcast and Broadband Television (HbbTV) 2.0 standard: (HbbTV_specification_2_0:2015), (hereinafter “HbbTV 2.0”), specifies services to support companion screens. The methods to allow for interaction between HbbTV and Companion Screens are described in HbbTV 2.0. Whilst primarily targeted at iOS and Android devices, the framework described in HbbTV 2.0 should allow Companion Screens of any type to be used. The HbbTV terminal and the Companion Screens have to be connected to the same local network, and the local network should be connected to the Internet. Following features are supported by HbbTV 2.0:                An HbbTV application launching a Companion Screen application        The Companion Screen application may be an HTML application running in a browser on the Companion Screen, or may be a native Companion Screen application. There is also the facility for the HbbTV application to direct the user to the location of a native application in a Companion Screen's ‘store’ (so that application can be downloaded) if it isn't already installed on the user's Companion Screen device.        A Companion Screen application launching a broadcast independent HbbTV application on an HbbTV terminal.        To allow an HbbTV application and a Companion Screen application to communicate directly by establishing a communication channel onto which text or binary messages can be exchanged, regardless of the launch methods of either the HbbTV application or the Companion Screen application.        To enable a companion screen or another HbbTV terminal to locate the services, provided by the HbbTV terminal.        
HbbTV 2.0 does not define actual message content, message formats and various types of message exchanged between a primary device and a companion device. In contrast this disclosure describes this type of information.
Additionally in the prior art The Common Alerting Protocol (CAP) (http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities. CAP includes:                Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions;        Multilingual and multi-audience messaging;        Phased and delayed effective times and expirations;        Enhanced message update and cancellation features;        Template support for framing complete and effective warning messages;        Compatible with digital signature capability; and,        Facility for digital images and audio.        
Key benefits of CAP may include reduction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the “native” formats of different kinds of sensor and alerting technologies, forming a basis for a technology-independent national and international “warning internet.” Where as CAP message format provides a general framework it may be too complex for emergency alert message communication between a primary device and a companion device The proposed protocol in this disclosure related to emergency alert information exchange between a primary device and companion device is lightweight and efficient.
The foregoing and other objectives, features, and advantages of the invention will be more readily understood upon consideration of the following detailed description of the invention, taken in conjunction with the accompanying drawings.